Follow-up to #975 and #980: the CAS-then-Start pattern for retargeting
m_timerDue had a TOCTOU window where thread A could win the CAS but
before calling Start(), thread B could CAS+Start an earlier deadline,
which thread A's Start() would then overwrite — stranding the earlier
callback until independent traffic arrived.

The fix in #980 added post-Start verification in SubmitPendingCallbacks,
but the same unguarded pattern existed in QueueItem and
PromoteReadyPendingCallbacks.

This change extracts the CAS+Start+verify logic into three helpers
(ArmTimerIfEarlier, ArmNextPendingCallback, RearmObservedDueTime) so
the post-Start verification is applied uniformly at every call site.
~67 lines of duplicated inline CAS logic removed.

Follow-up to #975 and #980: the CAS-then-Start pattern for retargeting
m_timerDue had a TOCTOU window where thread A could win the CAS but
before calling Start(), thread B could CAS+Start an earlier deadline,
which thread A's Start() would then overwrite — stranding the earlier
callback until independent traffic arrived.

The fix in #980 added post-Start verification in SubmitPendingCallbacks,
but the same unguarded pattern existed in QueueItem and
PromoteReadyPendingCallbacks.

This change extracts the CAS+Start+verify logic into three helpers
(ArmTimerIfEarlier, ArmNextPendingCallback, RearmObservedDueTime) so
the post-Start verification is applied uniformly at every call site.
~67 lines of duplicated inline CAS logic removed.

Co-authored-by: Jason Sandlin <jasonsa@microsoft.com>

#975 rewrote the shared STL wait-timer backend (WaitTimer_stl.cpp) to replace
the O(N) pointer-keyed cancellation scan with an O(log N) per-timer generation
scheme: every Start() bumps a generation counter and pushes a fresh heap entry,
and the worker discards any popped entry whose generation no longer matches the
timer's current generation.

That scheme can drop a due callback. A Start() that races the worker between
its Peek() of the earliest entry and its dispatch of that entry bumps the
generation, so when the worker pops the entry it now reads a stale generation
and discards it instead of firing it. The re-pushed entry carries a new
deadline, so the original due callback is never delivered. With the entry gone,
the worker sleeps on the next (later or absent) deadline and goes idle.

On a single-port manual XTaskQueue this is unrecoverable: the platform HTTP
provider re-arms its poll via XTaskQueueSubmitDelayedCallback, and once that
re-poll is dropped there is no independent traffic to wake the queue and sweep
the pending list again. The symptom is an infinite sign-in / inventory hang
(the delayed re-poll sits in the pending list while the timer thread waits in
_Cnd_timedwait, never re-armed).

Why the arming-layer fixes did not catch or fix it:
- #975, #980 and #983 (#983 = "Centralize timer-arming to close TOCTOU race")
  all hardened the CAS->Start bookkeeping in TaskQueuePortImpl (m_timerDue) in
  TaskQueue.cpp. Those fixes are correct and are retained here. But they assume
  Start() reliably arms the backend for the published deadline. The generation
  backend violates that assumption by dropping the entry after Start(), so no
  amount of arming-layer verification can recover it.
- The defect only affects WaitTimer_stl.cpp. Win32/UWP use WaitTimer_win32.cpp
  (OS CreateThreadpoolTimer, no generation scheme) and are unaffected. The
  libHttpClient unit-test project compiles the Win32 backend, so the Windows
  suite stayed green and none of #975/#980/#983 exercised the STL backend.

Fix: restore the proven pre-#975 STL backend algorithm (libHttpClient 2.3.1,
commit 0fa5f24) - pointer-keyed cancellation and an unconditional notify on
every Set, which cannot discard a due entry - bridged to the post-#975 public
WaitTimer API (GetCurrentTime / GetDueTime / Start(dueTime)). The clock is
pinned to steady_clock (the pre-#975 code used high_resolution_clock, which is
steady_clock on libc++ but wall-clock system_clock on libstdc++); pinning keeps
the delayed-callback ordering monotonic on every platform that compiles this
backend, preserving #975's monotonic-time intent.

The arming-layer improvements in TaskQueue.cpp from #975/#980/#983 are kept
unchanged; only the STL timer backend is reverted.

Validated on-device in a shipping title: the reproducing infinite sign-in /
inventory hang no longer occurs with this backend and the current TaskQueue
arming logic.

Follow-up: the STL backend has no unit-test coverage (the test project compiles
only the Win32 backend). A dedicated STL-backend test lane is needed so a future
re-land of the generation optimization cannot reintroduce this class of strand.